Часть 4. Оптимизация клиент-серверного взаимодействия в формах

Глава 4.1. Общие рекомендации по оптимизации клиент-серверного взаимодействия

Форма должна быть «легкой», доступной в веб-клиенте и работать максимально быстро даже при использовании низкоскоростных каналов связи. Данные формы присутствуют как на клиенте, так и на сервере и автоматически синхронизируются при клиент-серверном взаимодействии.

Передача данных между сервером и клиентом происходит во многих случаях – например, при открытии формы и записи данных платформа сама преобразовывает прикладные объекты в данные формы и обратно. При контекстных вызовах процедур модуля формы все изменения данных формы и ее элементов платформа передает на сервер и обратно, и т. д.

Однако нужно понимать, что любое обращение на сервер – это непростой процесс. Платформа формирует обращение к серверу, передает его по каналу связи, выполняет какие-то действия на сервере, возвращает ответ по каналу связи… При работе тонкого клиента через GPRS каждый вызов сервера занимает примерно 1,5 секунды. Это, естественно, сказывается на быстродействии прикладного решения.

Поэтому разработку прикладного решения необходимо вести с контролем количества вызовов серверных процедур и функций из клиентского кода, а также объема передаваемых данных между клиентом и сервером (трафика).

Общее количество серверных вызовов складывается:

• из обращений на сервер, которые выполняет платформа «1С:Предприятие»;
• вызовов, которые выполняются из клиентского кода конфигурации разработчиком.

Если рассматривать источник этих вызовов, то существует несколько категорий серверных вызовов:

• Вызовы, которые платформа делает в результате того, что пользователь совершает какие-то интерактивные действия. На это разработчик повлиять не может.
• Вызовы, которые платформа также делает самостоятельно, но при выполнении определенных методов или свойств программного кода. На это разработчик может повлиять, если попробует использовать другие методы, свойства или изменить алгоритм.
• Серверные вызовы, которые разработчик делает в явном виде в коде.

Таким образом, разработчику при проектировании клиент-серверного взаимодействия в конфигурации нужно стремиться минимизировать количество вызовов сервера, которые он инициирует своим кодом.

Также разработчику нужно оптимизировать не только количество вызовов, но и объем передаваемых данных между клиентом и сервером (трафик). Неэффективность решения особенно будет заметна при работе через низкоскоростные каналы связи. Чтобы визуально оценить скорость работы на плохом канале связи, рекомендуется запускать клиентское приложение в режиме низкой скорости соединения, а в параметрах системы включать режим имитации задержек при вызове сервера.

С другой стороны, нужно минимизировать и объем кода, выполняющегося на клиенте. Это требование продиктовано:

• тем, что, как правило, клиентский компьютер менее производительный, чем серверный компьютер;
• необходимостью приемлемого качества работы в веб-клиенте. Клиентский код выполняется интерпретатором встроенного языка, который в веб-клиенте работает медленнее, чем в тонком или толстом клиенте.

В связи с этим методика оптимизации клиент-серверного взаимодействия базируется на следующих общих рекомендациях:

• Клиент и сервер рассматриваются как два взаимодействующих приложения.
• Разработчик программирует в явном виде серверную и клиентскую части конфигурации.
• Структура кода определяется логикой клиент-серверного взаимодействия, а не логикой того прикладного алгоритма, который реализует разработчик.
• Клиентский код продумывается не как последовательность действий, которую нужно выполнить, а как сценарий передачи управления между клиентом и сервером.
• Разработчик должен минимизировать частоту вызовов сервера. В идеале одному действию пользователя должен соответствовать один вызов сервера. Например, «хорошим тоном» разработки считается открытие формы за один серверный вызов. Конечно, эту рекомендацию нельзя считать строго обязательной, но желательно к этому стремиться.
• Разработчик должен пытаться сократить трафик – объем передаваемой между клиентом и сервером информации.
• Нужно реализовывать алгоритмы так, чтобы было минимум кода на клиенте, но и минимум обращений к серверу.

Важно понимать, что стремление оптимизировать код конфигурации должно иметь разумные пределы. Не нужно слепо следовать инструкциям и впадать в крайности. В погоне за оптимизацией можно сделать программный код совершенно нечитаемым. То есть за приемами оптимизации уже не будет видно собственно самой прикладной задачи, которая реализуется этим кодом.

В этом случае поддержка такого кода станет очень сложным делом. Человек, который не принимал участия в написании этого кода, скорее всего, просто не станет раскапывать этот кладезь оптимизации. А сам разработчик через полгода – год тоже с большим трудом сможет разобраться в том, что же он написал…

Таким образом, нужно искать золотую середину между стройным читаемым кодом и его оптимизацией. Не нужно всегда бездумно стремиться только к одной лишь оптимизации.